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(57) Abstract: The scope of discovery protocols on network domains of devices and services is extended. A search message or 
an announcement message on a multicast channel in one domain gets encapsulated into a unicast message thai is sent to a second 
domain. The multicast message is extracted from the unicast message in the second domain and is input to the second domain's 
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Multicast discovery protocol uses tunneling of unicast message 



The invention relates to aspects and use of discovery procedures on a multi- 
domain netwoik. 

Home network architectures such as HAVi, UPnP, Jini and VESA typically 
contain a device discovery protocol This protocol is i^ed to implement plug-and-play 
5 behavior, i.e., when a device is plugged into the network (or - in the wireless case - comes 
within range) it is automatically discovered by all iuterested parties, and can be used 
immediately* IP-based home networl^ such as UPnP and Jini build their discovery protocol 
on top of IP multicasting. Li this case, a standard IP address and port are standardized as the 
multicast chaimeL Devices that join the network and want to announce themselves to the rest 

10 of tiie netwoik send certain announcement messages to this channeL Devices that want to 
discover new devices simply listen to this chamel. 

Automatic discovery of devices is particularly important for wireless devices 
such as PDAs or mobile phones that enter or leave the (home) network, together with the 
person carrying them. However, automatic discovery is also relevant to non-mobile devices. 

15 These devices may be turned on or off by users at will, and in that sense enter or leave the 
netwoik. Another reason why automatic discovery is important is the volatile nature of IP 
addresses. Typically, IP address allocation schemes such as DHCP assign IP addresses to 
devices on a temporary basis. In other words, a device discovered yesterday at IP address "A" 
mig^t have IP address "B" tomorrow. The discovery protocol offers a mechanism for this 

20 device to announce itself at Ibis new address, thereby ensuring tiiat all interested climts 
become aware of this new address. Even if the device has not left or entered the home 
network fiom a user point of view, it has Jfrom a network point of view. Hence, discovery is 
not just a one-time-only activity performed whai a device is brought home from a store and 
placed into a home network. Rather, it is a setup process that needs to be performed every 

25 time a user or application wants to use and control certain types of devices. 

Discovery based on IP multicasting gives rise to some problems. For example, 
P multicasting is not gmeraUy supported tiirou^ut the whole hitemet Many IP routers and 
firewalls/gateways simply block all multicast traf&c. As another probl^atic aspect, IP 
multicasting does not scale. A multicast message needs to have a Time-To**Iive (TTL) field 
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specifying the scope of the multicast message. The TTL field specifies the number of routers 
that this packet may traverse, and is needed to avoid flooding the whole latemet with these 
messages- The IP multicast routing protocol uses tixe TTL field of IP datagrams to decide 
how "far" firom a sending host a given multicast packet should be forwarded The defeult 
5 TTL for multicast datagrams is unity, which results in multicast packets going only to ottier 
hosts on the local network. It is generally impossible to know the number of routers in a pafli 
between two devices. Hence is it g^erally unknown to predict a sensible TTL value, and 
there is no guarantee m advance that a multicast message will reach all relevant destinations. 

The inventor has realized that a TTL value can be used to specify clusters of 

10 devices that can discover each other. An aspect of this invention relates, among other things, 
to a mechanism to connect multiple ones of such clusters via "tunneling" of these multicast 
messages inside point-to-point (or uuicast) messages exchanged between Extended 
Discovery Servers. The result is that devices and ^plications in separate clusters, residing at 
locations rotnote &om each other and connected through these servers, can now discov^ and 

15 control each other. 

An aspect of the invention therefore relates to a method of bridging a plurality 
of multicast domains. A multicast message, originating in a specific one of the domains, is 
enabled to be transferred as a unicast message to at least another one of the domains. Then, 
the multicast message is enabled to be re-generated fix>m the unicast message in the other 

20 domain. 

Another aspect of the invention relates to hardware or a software component 
for use on a first multicast donoain, e.g., a first part of a home network. The component is 
operative to encapsulate a multicast message in a unicast message for bemg sent to a second 
multicast domain, e.g., a second part of the home network. 
25 The invention allows to extend the scope of discovery protocols via multicast 

tunneling and reference translation: a search message or an announcement message on a 
multicast channel in one domain gets enc^sulated into a unicast message that is sent to a 
second domain. The multicast messagejs extracted fiom the unicast message in the second 
domain and is input to the second domain's multicast chaimel. 

30 

The invention is explained below in finther detail, by way of example, and 
with reference to the acconapanying drawings, wherein: 



wo 03/030452 PCT/IB02/03778 

3 

Figs, i and 2 are event diagrams illustrating searching and announcement 
events in a multicast domain; 

Figs. 3 and 4 are event diagrams illustrating the tunneling of a multicast 
messages between two multicast domains; 
5 Figs. 5 and 6 are event diagrams illustrating the tunneling between multicast 

domains with a UPnP configuration. 

Throughout the figures^ same reference numerals indicate similar or 
corresponding components or features. 

10 

Figs. I and 2 are event diagrams illustrating searching and announcing events 
ui a single multicast domain. A typical discovery protocol involves devices (or software 
^plications) that assume one of two possible roles: on the one hand a controlled device or 
server; and on the other hand a controller device or client s^lication. A discovery protocol 
15 implements active searching by controller devices for controlled devices (of a particular 
type). 

In Fig. 1, a controller device 102 sends a search message 104 to a multicast 
channel 106. Controlled devices 108, 1 10 and 112 listen to multicast channel 106. Relevant 
ones of controlled devices 108-112 send unicast responses 114 and 116 to device 102» the 
20 sender of search message 1 04. 

In Fig. 2, controlled devices 108 and 208 send announcement messages 202 
and 204 to multicast channel 106 to aimounce their presence, e.g., periodically or upon a 
certain event such as "power-on" or "coming within range" as for device 208. Controlled 
device 110 sends announcement messages 206, to multicast channel 106 to announce its 
25 imminent disappearance (e.g., in case of a power shutdown). 

Search responses 1 14 and 116 and presence announcements 202 and 204 
contain respective references to tiie n^ective discovered devices. A reference comprises, 
e.g., an IP address or a URL. Subsequent interaction with the discovered device is based on 
this reference. 

30 This invention introduces a software component referred to herein as an 

**Bxt»ded Discovery Server^' (EDS) fliat can be added to a (home) network in order to 
amble the devices on this netwodc to discov^ (or be discovered) and be used by remote 
devices. The EDS needs to be connected, tibrou^ the Memet or another Wide Area Network 
(WAJJ), to one or more remote EDSs. It needs to know global references to these EDSs, such 



wo 03/030452 PCT/IB02/03778 

4 

as static global IP addresses or registered Internet domain names. The operation of an EDS is 
described below for two scenarios: a controller device searches for remote devices to interact 
with, and a controlled device announces its presence or imminent disappearance to remote 
control!^ devices. 

5 Fig. 3 illustrates a scenario with events in a domain 302 and a domain 304, 

e.g.» Homel and Hom^, respectively. Domain 302 has an EDS 306 and domain 304 has an 
EDS 308. EDSs 306 and 308 enable to share thek networks, i.e., domains 302 and 304, with 
one another. EDSs 306 and 308 both hsten to messages on multicast channels 310 and 312. 
hi the example shown, a search message 3 14 is detected by EDS 306 in domain 302. EDS 

10 306 encapsulates multicast message 3 14 together with a reference to the multicast sender, 
here a device 316, in a new unicast message 318. In case origmal multicast sender 316 in 
domain 302 was using a local reference, that reference is translated via, for example, NAT, 
and replaced by an equivalent global reference. EDS 306 then sends encapsulated multicast 
message 318 as unicast message via WAN 326 to one or more other EDSs that it wants to 

IS share devices with. In this exantple, the relevant other EDS is EDS 308. When EDS 308 
receives message 318 from EDS 306, the fonn^ extracts the encapsulated search message 
314 and the global reference of original multicast sender 316. EDS 308 then sends extracted 
search message 320 to a multicast channel 312 in domain 304. Thus, original multicast 
message 314 is regenerated in a different multicast domain as if it has tuimeled from domain 

20 302 via WAN 326 into domain 304. Smce EDS 308 is the sender of regenerated multicast 
message 320, it will receive the response, if any, to tbis search message. Each response 
received from devices in domain 304, e.g., devices 322 and 324, will be forwarded to sender 
316 of the origmal search m domain 302. In case the responses contain local references, those 
references are translated via, for exantple, NAT, and replaced by equivalent global 

25 references. Now that controller device 3 16 in domain 302 has discovered controlled device 
322 in domain 304 fliat it searched for, it can use the reference received to interact with 
device 322. The actual mechanism to implement this is independent of this invention. 
Usually, these mechanisms are based on unicast, such as HTTP. 

Fig* 4 illustrates a scenario with events in domains 302 and 304, wherein a 

30 device 406 announces its presence. EDSs 306 and 308 listen to messages on the standardized 
multicast channels 310 and 312, respectively. Whenever an announcement message 404 is 
detected by an EDS, m Ibis scenario by EDS 308 m domain 304, the relevant EDS 
enc£f»sulates the entire multicast message 404. In case announcement 404 contains a local 
refermce,.e.g., to its sender device 406, that refiarence is translated via, for example, NAT 
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and replaced by an equivalent global reference. EDS 308 then sends the encapsulated 
multicast message 408 as nnicast message via WAN 326 to one or more other EDSs, in this 
scenario, EDS 306. When EDS 306 receives unicast message 408 from EDS 308, the fomier 
extracts encapsulated announcement message 404 from message 408, EDS 306 then sends 
the extracted announcement message 412 to multicast channel 310 in domain 302. Thus, 
original multicast message 404 is regenerated in a dijBFerent multicast domain as if it had 
tunneled from domain 304 via WAN 326 to domain 302. Now that announcement 404 has 
been regenerated in domain 302 as message 412, controller devices in domain 302 are aware 
of new device 406 in domain 304 and can interact with device 406 through the reference 
contained in announcement message 412. The actual mechanism to do this is mdependent of 
this invention- Usually, these mechanisms are based on unicast, such as HTTP. 

The invention allows entities Uiat can be discovered within a single domain^ 
e.g., a home network or another restricted area, to be discovered by remote applications, in a 
controlled way. The entities can be devices such as those based on UPnP, services, individual 
pieces of audio/video (AV) content information, or even persons associated with a personal 
device such as a PDA or mobile phone. The reach of the extended discovery protocol is 
determined by the set of EDSs that know each other^s network address. 

For example, a group of three friends might decide to share their home 
networic by establishing a relation between their EDSs. Another example is a mobile 
professional that establishes a relation between his EDS at home and his EDS at work or 
vacation location. The actual mechanism to establish these relations is indq)endent of the 
object of this invention. 

After discovery of a remote entity throu^ the EDS mechanism, the entity may 
be used/controlled. For example: a security camera in a home may be inspected from a work 
or vacation location; a song or video stored in a friends home may be downloaded or 
streamed to your own home; a VCR in a home may be programmed fix>m a remote location; a 
device may be turned off from a remote location, to save csiergy; one's home network can be 
monitored remotely to detect intrusions/abnormaUties such as devices disappearing without 
authorization or applications searching for devices at odd times of the day. 

An EDS may implement a filtering mechanism, to allow remote access only to 
certain devices in Oie home, or only at certain tim^ of the day, or only to certain 'trusted' 
remote EDSs. This filtering can also be personalized per us^. 

Figs. 5 and 6 illustrate the above in some more detail for multicast domains 
with UPnP configurations. The UPnP standard defines a discovay protocol referred to as 
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Simple Service Discovery Protocol (SSDP), It is used to discover either UPnP devices or 
UPnP services. In UPnP terminology, a service is a functional component that is part of a 
UPnP device. SSDP uses a standard multicast channel, 239^55.255250:1900, and a TTL of 
4. SSDP defines the following messages: 
5 - NOTIFY (ssdp: alive) : periodically sent by a controlled device to the 

multicast channel to amiounce its presence. Contains a URL reference to the devices* 
description document. 

- NOTI FY ( ssdp : byebye ) : sent by a controlled device to the multicast 
chamiel to announce its immin^t disappearance. 

10 -M-SEARCH (<search-target>) : sent by a controller device to the 

multicast channel to search for specific device types, service types, device instances or all 
devices. Controlled devices that match the <seaich target> need to respond to die sender of 
the search with a message containing a URL reference to the device's description document 
After a controller device has used SSDP to discover a device that it is 

1 5 interested in, it has the URL to the device's document It can subsequently fetch this 

document and parse it to find references to the services (= functional components) that the 
device contains. It can then use those references to actually interact with this device. The 
references are in the form of URLs, and interaction is based on using the HTTP protocol (via 
a POST message) between controller device and controlled device. 

20 In some homes, the URL refermces that a device uses to announce itself are 

based on a so-called 'local' IP address, meaning that the address is not globally unique, and 
the VSL reference is not usable on the global Internet In such a home, at least one device - 
e.g., the Internet Gateway - has a global IP address. This Internet Gateway typically 
implements NAT (Network Address Translation) or NAPT (Netwo± Address Port 

25 Translation), which is a mechanism to map a local IP address plus port to a global IP address 
plus port. The EDS can use this mechanism to r^lace local addresses by a global address for 
all SSDP messages that leave the home to travel the Internet and anive at a remote home. 
Specifically, dns concerns the following mess^es: 

-NOTIFY (ssdp: alive) of a local device; 

30 - response to a remote SEARCH (<search-target>) message; 

In this embodiment, the unicast message used to tunnel is an HTTP POST 
mechanisnL The HTTP body contains the complete SSDP message (the SSDP header + 
body) plus, in case of an SSDP search, the IP address and port of the sender. This latter 
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infonnation is encoded as an HTTP header called 'ORGINAL-MCAST-SENDER'. The 
EDSs in this embodiment know each other, in the fomi of a URL reference. 

More specifically, a tunneled search message looks like this: 
POST <path of URL of EDS> HTTP/1.1 
5 M-SEARCH * HTTP/1.1 

HOST; 239,255.255.250:1900 
MAN : " ssdp : discover" 
MX: oeconds to delay response> 
ST: <search target> 
10 ORGINAL-MCAST- SENDER: <global IP address and port of the multicast 
sender> 

A tunneled announcement of presence message looks like this: 
POST <path of URL reference of remote EDS> HTTP/1.1 
15 NOTIFY * HTTP/1.1 

HOST: 239.255.255.250:1900 

CACHE-CONTROL: max-age = oeconds until advertisement e3q>ires> 
LOCATION: <global URL reference to the devices 
NT: <search target> 
20 NTS: "ssdp:alive" 

SERVER: <OS/verBion> UPnP/l.O <product/version> 
USN: <advertisement UUID> 

A tunneled announcCTient of inuninmt disappearance message may look like: 
25 POST <path of URL of EDS> HTTP/1,1 

NOTIFY * HTTP/ 1.1 

HOST: 239.255.255.250:1900 

NT: <search targets 

NT : " s sdp : byeby e " 
30 USN: <advertisement UUID> 

The HTTP POST response to this would be a standard ok response, in all 

cases: 

HTTP/1.1 200 OK 

35 
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Parts of the above messages that are enclosed in brackets and ">") are not 
to be taken Uterally, but are to be interpreted as defined in the UPnP SSDP specification. 

Figs. 5 and 6 are event diagrams showing the scenarios for search tunneling 
coireaponding to Fig. 3» and for aimouncement tonneling corresponding to Fig. 4. The events 
have been rephrased in terms specific to ttiis UPnP/SSDP/HTTP embodiment. 
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CLAIMS: 



1 • A method of bridgrag a plurality of multicast domains, the method 

comprising: 

enabling to transfer a multicast message, originating in a specific one of the 
domains, as a unicast message to at least another one of the domains; 
5 - enabling to regen^ate the multicast message from the unicast message in the 

other domain. 

2. The method of claun 1 , wherein the multicast message comprises a search 
message for discovery of a device or service. 

10 

3 . The method of claim 1 , wherein the multicast message comprises an 
announcement message for announcing the presence of a device or service. 

4. The method of claim 1, wherein at least part of the sfpecific domain or the 
15 other doniain forms part of a wireless netwoik. 

5. The method of claim 1 , using IP multicasting. 

6. The method of claim 1, wherein at least one of the domains has a UPnP 
20 architecture. 

7. A unicast message on a data netwoifc, a multicast nlessage being encapsulated 
in the unicast message. 

25 8. A component for use with a multicast domain, the component being operative 

to encapsulate a multicast message, received from a multicast channel in the multicast 
domain, in a unicast message. 
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9- A component for use with a multicast domain, the component being operative 

to extract a multicast message from a unicast message foi forwarding the multicast message 
to a multicast channel of the multicast domain. 
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